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"EXTENDING SIP FOR UPLOADING SUBSCRIBER'S SERVICE PROFILE 

FROM HSS TO CSCF" 



5 



Field of the invention 

The present invention relates to a method a network 
10 system for transmitting subscriber information from a 
first network element to a second network element. 



BACKGROUND OF THE INVENTION 

15 

The present invention concerns the so-called subscriber 
profile. The subscriber profile holds subscription 
information about services and other parameters that have 
been assigned to a subscriber for an agreed contractual 

20 period. It includes information regarding sxibscribed 
services, subscribed QoS (Quality of Service) profile 
(i.e,, service precedence (priority) , reliability, delay, 
throughput) etc. The data included in the subscriber 
profile are needed by the network element executing the 

25 service in order to handle the calls. 

The siibscriber profile includes for a given user, e.g., 
user identities, subscribed services and profiles, 
service specific information, mobility management 
30 information, authorization information etc. 

In the 3GPP (Third Generation Partnership Project) 
Release 2000 (in the following referred to as ROO) , this 
data are hold in the HSS (Home Subscriber Server) . Thus, 
35 the HSS is the master database for a given user. It is 
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responsible for keeping a master list of features and 
services (either directly or via servers) associated with 
a user, and for tracking of location of and means of 
access for its users, i.e., provides the subscriber 
5 profile. 

During normal calls, this subscriber profile is required 
by other network elements which handle the calls. Hence, 
the subscriber profile has to be conveyed to these other 
10 network elements. 

Such a network element is a so-called Call State Control 
Function, for example. The CSCF is the call control 
entity in the all -IP architecture responsible for 
15 supervising the call (or IP multimedia call) . It handles 
the call establishment, supervision and disconnection 
signalling and may control resources associated with the 
call such as media gateways processing the various call 
related media streams. 

20 

A CSCF can fulfill different roles in an IP multimedia 
call signaling path, for example as a Serving CSCF (S- 
CSCF) , an Interrogating CSCF (I -CSCF) or an Originating 
CSCF (0-CSCF) , depending on which function it fulfills 
25 during a call. 

The Serving CSCF supports the signalling interactions 
with the UE (User Equipment) , in particular, it provides 
a Serving Profile Database (SPD) described below. The 
30 Home Subscriber Server (HSS) is updated with the Serving 
CSCF address and the HSS sends the subscriber data to the 
Serving CSCF for storage. 

The Interrogating CSCF (I-CSCF) is used for mobile 
35 terminated communications and is used to determine how to 
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route mobile terminated calls. The Interrogating CSCF 
interrogates the HSS for information to enable the call 
to be directed to the Serving CSCF. 

5 Moreover, an Originating CSCF (0-CSCF) is the CSCF where 
the originating party is registered and where the 
originating party services are handled. On the -other 
hand, the S-CSCF is the CSCF where the terminating party 
is registered and where the terminating party services 
10 are handled. 

For mobile terminated communications both Serving CSCF 
and Interrogating CSCF ftinctionality can be involved. For 
mobile originated communications Interrogating CSCF 
15 functionality is not required. 

For controlling a call between the different CSCFs and 
the UE connected thereto, a call control protocol is 
required. One of such call control protocols is the so- 
20 called Session Initiation Protocol. In the following, 
some aspects of SIP are described in short. 

SIP is a general -purpose tool for the initiation, 
modification, and termination of sessions. That is, SIP 

25 is an application- layer control (signalling) protocol 
that can establish, modify and terminate multimedia 
sessions or calls with one or more participants. These 
sessions include Internet multimedia conferences, 
Internet telephone calls, multimedia distribution and 

30 similar applications. Members in a session can 

commimicate via multicast or via a mesh of unicast 
relations, or a combination of these. As a core part of 
its functionality, SIP carries the ports, IP addresses 
and domain names needed to describe the sessions it 

35 controls. 
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SIP can be used to initiate sessions" as well as to invite 
members to sessions that have been advertised and 
established by other means. 

5 

In the following, items concerning SIP are described 
^ which are necessary for understanding the present 
invention. 

10 In SIP, a plurality of different requests are exchanged. 
A request is composed by a request line followed by a 
header and, optionally, a message body. 

In the following, an example a for request is listed: 

15 

INVITE sip: UE (B) @HSS . ipt . operator . com SIP/2.0 
Via: I-CSCF. ipt. operator, com 
From: UE (A) 

To : UE (B) ®ipt . operator . com 
20 Content -type: application/ sdp 

Content-length: . . . 

<SDP information in the message body> 

25 The request line is made up as follows: 

Request-Line = Method Request-URI SIP-Version 

A method is a predefined procedure. Currently, in SIP the 
30 methods INVITE, ACK, OPTIONS, BYE, CANCEL and REGISTER 
are defined. For simplifying the description, only the 
methods INVITE and ACK are described in the following as 
examples in short . 
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The INVITE method indicates that a user is being invited 
to participate in a sessions. Thus, the message body of a 
corresponding INVITE request contains a description of 
the session to which the callee is being invited. 

5 

The ACK method is used in the ACK request to confirm that 
a client has received a final response to an INVITE 
request. ACK is used only with INVITE requests. The ACK 
request may contain a message body with the final session 
10 description to be used by the callee. If the ACK message 
body is empty, the callee uses the session description in 
the INVITE request. 

The request-URI is a SIP URL (Uniform Resource Locator) 
15 or a general URI (Uniform Resource Identifier) . It 

indicates the user or service to which this request is 
being addressed. 

Furthermore, the request-line comprises the SIP version 
20 (e.g., SIP/2.0) in order to indicate the recipient which 
SIP version is used. 

The header of the SIP request comprises a plurality of 
fields. In the following, only those fields are described 
25 in short which are important for the present embodiment. 

A field "Via" indicates the path taken by the request so 
far. This prevents request looping and ensures replies 
take the same path as the requests, which assists in 
30 firewall traversal and other unsusual routing situations. 
That is, each time a request is proxied, a new Via-field 
is added. 
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A field "From" indicates the initiator of the request, 
whereas the field "To" indicates the recipient of the 
request . 

5 A field "Content -Length" indicates the size of the 

message body, in decimal number of octets, sent to the 
recipient - 

A field "Content -Type" indicates the media type of the 
10 message body sent to the recipient. 

A field "Call- ID" uniquely identifies a particular 
invitation or all registrations of a particular client. 

15 A field "CSeq" indicates a command sequence. It contains 
the request method (e.g., INVITE) and a single decimal 
sequence number chosen by the requesting client. 

The message body comprises , for example, a description of 
20 the multimedia connection to which a recipient is 

invited. For example, the so-called Session Description 
Protocol (SDP) is used for this purpose. 

On receiving a request, the recipient can send a 
25 response. For example, in case of an INVITE request, the 
recipient can agree to participating in the call by 
sending a so-called 200 OK response. A response Is 
basically similar to a request, although the request-line 
is replaced by a status-line which in particular 
30 comprises a status code, which is in the above example 
200. This value indicates OK. The header of a response 
can contain similar fields as the request. For example, 
in case of an 200 OK response to an INVITE request, the 
CSeq field contains the same value, e.g., INVITE 1. 

35 
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In Fig, 1, a basic example, for network including the 
above- described network elements is shown. In detail, two 
User Equipments (UE) UEl and UE2, and a plurality of 
CSCFs are shown. 0-CSCF and I-CSCF comprise a Subscriber 
5 Profile Database (SPD) and each CSCF comprises a SIP 
message processor for handling the' SIP ^ requests and 
responses. As mentioned above, whether a certain CSCF is 
an 0-CSCF, an I-CSCF or an S-CSCF depends on the function 
the CSCF- has to fulfill. 

10 

In this example, UEl- originates a call to UE2. Thus, the 
CSCF to which it is connected, is an 0-CSCF. The 0-CSCF 
forwards a call request to an I-CSCF which, I'n turn, 
tries to obtain the address of UE2's S-CSCF by referring 
15 to an HSS. The I-CSCF obtains the address of the 
corresponding S-CSCF of UE2 and forwards the call 
thereto . 

It is noted that in Fig. 1 the SPD in the 0-CSCF and the 
20 S-CSCF has to interact with the HSS in the home domain to 
receive profile information for the ROD all-IP network 
user and store them. Furthermore, it notifies the home 
domain of initial user's access. In addition, it may 
cache access related information (e.g. terminal IP 
25 address (es) where the user may be reached etc.). 

In this example, only the I-CSCF has to access the HSS 
for obtaining information regarding the location etc. of 
UE2. Thus, the CSCF has to obtain a subscriber profile 
3 0 from a HSS in order to handle the call according to UE2 » s 
services . 

In ROO, there is defined an interface Cx between the HSS 
and the CSCF. However, it is not defined yet how a 
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subscriber profile can easily be uploaded from the HSS to 
an CSCF via this interface. 

5 SUMMARY OF' THE INVENTION 

Therefore, the object underlying the invention resides in 
removing the above drawbacks of the prior art. 

10 This object is solved by a method for transmitting 

subscriber information from a first network element to a 
second network element, comprising the steps of 

inserting subscriber information in a specific 
message of the same call control protocol that is used to 
15 establish the call; and 

sending the specific message from the first network 
element to the second network element , 

In addition, the invention proposes a network system 
20 comprising a first network element and a second network 

e 1 ement , whe re in 

the first network element is adapted to insert 

subscriber information in a specific message of the same 

call control protocol that is used to establish the call, 
25 and to send the specific message to the second network 

element . 

Thus, according to the invention the subscriber 
information are inserted in a specific message of the 
30 same call control protocol that is used to establish the 
call . 

Therefore, according to the invention, an easy way of 
subscriber information uploading from one network element 
35 to another is provided. 
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An advantage of the invention is that there is no need 
for an additional protocol for profile uploading 
purposes. That is, the same call control protocol used 
5 for other call control purposes in the network can be 
used. Thus, the system can be kept less complex. 

In case the subscriber information have been received 
successfully by the second network element, a 
10 confirmation message may be sent from the second network 
element to the first network element. Thus, a successful 
uploading can easily be indicated to the first network 
element. 

15 The call control message can be a PROFILE request based 
on the Session Initiation Protocol (SIP) , the subscriber 
information being inserted in the message body of the 
request. That is, according to the invention, a new SIP 
method for profile uploading purposes is introduced. 

20 Since SIP is already chosen as the call control protocol 
in ROO, for example, no complex additional protocol is 
required, only an extended SIP (i.e., SIP including the 
new PROFILE request) is necessary. 

25. The confirmation message is a SIP 200 OK message. In 

addition, the other SIP responses can be used to indicate 
failure situations. 

The subscriber information can be a subscriber profile. 

30 

The first network element can be a Home Subscriber Server 
(HSS) and the second network element can be a Call State 
Control Function (CSCF) . Thus, the invention provides a 
protocol for conveying subscriber information via the Cx 
35 interface. 
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The Call State Control Function (CSCF) may be a Serving 
Call State Control Function (S-CSCF) or an Interrogating 
Call State Control Function (I -CSCF) , 

5 

Alternatively, the first network element can be a Serving 
Call State Control Function (S-CSCF) and the second 
network element can be an Interrogating Call State 
Control Function (I -CSCF) . Thus, also uploading between 
10 two CSCFs is possible- This is advantageous during a 
dynamic CSCF selection, for example. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 

The present invention will be more readily understood 
with reference to the accompanying drawings in which: 

Fig. 1 shows a network including UEs, CSCFs and HSS, 

20 

Fig. 2 shows a procedure for profile uploading according 
to an embodiment of the invention, 

Fig. 3 shows a procedure for registration on network 
25 level according to the embodiment, and 

Fig. 4 shows a procedure for call delivery according to 
the embodiment. 

30 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

In the following, a preferred embodiment of the invention 
is described in more detail with reference to the * 
35 accompanying drawings. 
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In particular, according to the embodiment described 
below, uploading of a subscriber profile from a first 
network element, e.g., a Home Subscriber Server (HSS) , to 
5 a second network element, e.g., a Call State Control 
Function (CSCF) is performed by using a specific call 
control protocol. This call control protocol is 
preferably also used in the network for other purposes.' 

10 In this embodiment, the Session Initiation Protocol (SIP) 
is used as the call control protocol. 

According to the present embodiment, SIP is extended for 
uploading subscribers' service profile from HSS to CSCF. 

15 

That is, according to the embodiment a new SIP method for 
profile downloading is introduced, which is referred to 
as the SIP PROFILE method in the following 

20 It should always be the HSS who initiates the PROFILE 
request, this request should contain the subscriber 
profile data. The CSCF should respond to the request in 
successful case with a 200 OK. 

25 There are several alternatives for subscriber profile 

data representation conveyed in the PROFILE request, e.g. 
XML (eXtendend Markup Language) , HTML {Hyper Text Markup 
Language) . In the present embodiment, HTML is used for . 
profile data representation. 

30 

Fig. 2 shows the profile uploading using the newly 
introduced PROFILE method. In step 1, the PROFILE request 
is sent to the CSCF, and the CSCF answers with a 200 OK 
response in case the subscriber profile was successfully 
35 received. 
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In the following, a PROFILE request including the new 
PROFILE method is listed: 

5 PROFILE sip: CSCF.ipt.operator.com SIP/2.0 

Via: HSS.ipt.operator.com 
From : UE@HSS . ipt . operator . com 
To : UE®ipt . operator . com 
Cal 1 - ID : 123456@HSS . ipt . operator . com 
10 Cseq: 1 PROFILE 

Content-type ; text/html 
Content -length: . , . 

<Subscriber profile represented with HTML> 

15 

That is, by the new PROFILE method, the subscriber 
profile is inserted in the message body. Hence, only this 
one message 1 (i.e., the PROFILE request) is necessary to 
2 0 transmit the subscriber profile to the CSCF. 

In case the message 1 was received successfully, the CSCF 
answers with a 200 OK response as follows: 

SIP/2.0 200* OK 
Via: HSS.ipt.operator.com 
From : UE®HSS , ipt . operator . com 
To : UE®ipt - operator . com 
Call - ID : 123456@HSS . ipt . operator . com 
Cseq: 1 PROFILE 
Content - length : 0 



25 2. 



30 
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Thus, if the HSS receives a 200 OK response, it knows 
immediately that the subscriber profile was successfully- 
transmitted. 

5 The profile uploading as mentioned above is basically 
needed in two major scenarios: registration and mobile 
terminated call delivery. 

Next, these two scenarios are described with reference to 
10 Figs. 3 and 4. 

Fig. 3 illustrates a registration procedure of a User 
Equipment UE. 

15 In message Al, a SIP REGISTER request is sent from the UE 
to the S-CSCF, The REGISTER request is used in order to 
register an address listed in the To header field with a 
SIP seiver. 

20 That is, the meaning of the header fields is defined 
slightly different from those of, e.g., the INVITE 
request. In detail, the To header field contains the 
address whose registration is to be created (or updated) . 
The From header field contains the address of the person 

25 (or entity) responsible for the registration. Since these 
addresses are not used in the way as they are in other 
request types (e.g., the INVITE request), they are 
referred to as "address-of -record" . The Request-URI 
(included in the request -line) names the destination of 

30 the registration request, i.e., the domain of the 
registrar. 

In the procedure illustrated in Fig. 3, message Al is a 
SIP REGISTER request. This message is received by the S- 
35 CSCF- 
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Al. REGISTER sip : S-CSCF . ipt . operator . com SIP/2.0 

Via: ab.cd.de: 11 //UE • s IP-address 

From : UEOipt . operator , com 
5 To: UE@ipt.operator.com 

In order to perform the requested registration of the UE, 
the S-CSCF has to know the sxibscriber profile. Hence the 
10 REGISTER request has to be forwarded to the HSS. The S- 
CSCF finds the domain name of HSS based on the value of 
the To header. S-CSCF proxies the REGISTER message 
further towards the HSS in message A2 . 

A2. REGISTER sip : HSS . ipt .operator . com SIP/ 2.0 
Via: S-CSCF. ipt.operator.com 
Via: ab.cd.de: :11. 11 
From : UE®ipt . operator . com 
To : UE@ipt . operator . com 

Thereafter, the HSS perfoanns profile downloading with the 
S-CSCF. This is effected as described above. 

That is, the subscriber profile is immediately inserted 
in a PROFILE request which is sent to the S-CSCF in A3. 
This is performed as described above with respect to Fig. 
2. That is, the PROFILE request is sent from the HSS to 
the S-CSCF which responds with a 200 OK response. 

On receiving the 200 OK message from the S-CSCF, the HSS 
knows that the subscriber profile downloading was 
successful and sends itself a 200 OK message A4 to the S- 
CSCF. 



15 



20 



25 



30 



35 
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A4. SIP/2. .0 200 OK 

Via: S-CSCF. ipt , operator . com 
Via: ab.cd.de: : 11. 11 
From : UE@ipt . operator . com 
5 To: UE@ipt.operator.com 

Cseq: 1 REGISTER 

This message is forwarded to the UE in message A5. 

10 

A5. SiP/2.0 200 OK 

Via: ab.cd,de: :11.11 
From : UE@ipt . operator . com 
To : UE@ipt . operator . com 
15 CSeq: 1 REGISTER 

After this message, the registration procedure has been 
successfully completed. 

20 

Next, as a further example where the profile downloading 
according to the present embodiment can be used, a call 
delivery is described below with respect to Fig. 4. 

25 It is noted that here, REP (Remote Endpoint) represents 
the originating side of the call, e.g., a XJE(A) and an O- 
CSCF together. 

In a first message Bl, an INVITE request is sent from the 
30 REP to the interrogating CSCF, i.e., the I-CSCF. 
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Bl, . INVITE sip:UE(B)@I -CSCF.ipt.operator.com SIP/2.0 
Via: REP 
From: UE(A) 

To : UE (B) @ipt . operator . com 
5 Content-type: application/sdp 

Content- length: ... 

<SDP information in the message body> 

10 

In message B2, the I-CSCF proxies the INVITE message to 
the HSS. 

B2. INVITE sip:UE (B)@HSS. ipt.operator.com SIP/2.0 
15 Via: I -CSCF.ipt.operator.com 

Via: REP 
From: UE (A) 

To : UE (B) ®ipt . operator . com 
Content- type : application/sdp 
20 Content -length: . . . 

<SDP information in the message body> 

25 In this case, the HSS gives the answer that UE(B) has 
- temporarily moved by responding with a 302 Moved 
Temporarily Response in message B3 . 
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B3, SIP/2.0 302 Moved temporarily 
Via: I - CSCF. ipt, operator. com 
Via: REP 
From: UE(A) 
5 . To: UE(B)®ipt. operator. com 

Contact : UE (B) ®S-CSCF . ipt . operator . com 

This request comprises a header field "Contact" which 
10 indicates a URL or URI where the user can be reached for 
further communications. 

Thereafter, the I-CSCF sends an acknowledgment ACK 
request to the HSS in message B4. 

15 

B4. ACK sip:UE(B)®HSS. ipt .operator, com SIP/2.0 
Via : I "CSCF . ipt , operator . com 
From: UE(A) 

To : UE (B) ®ipt . operator . com 

20 

At this point the HSS may initiate a profile uploading 
with the I-CSCF, if service control mechanism also 
resides in the I -CSCF. This is performed as described 
25 above with respect to Fig. 2 . That is, the PROFILE 

request is sent from the HSS to the I-CSCF which responds 
with a 200 OK response. 

Then, the I-CSCF proxies the INIVITE message to the S- 
30 CSCF in message B6. 
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B6. INVITE sip:UE{B)®S-CSCF, ipt.operator.com SIP/2.0 
Via: I-CSCF. ipt .operator. com 
Via: REP 
From: UE(A) 
5 To: UE (B) @ipt .operator .com 

Content -type : application/ sdp 
Content -length: ... ^ 

<SDP information in the message body> 

10 

Thereafter, a regular call setup is continued- Thus, a 
detailed description of the following messages is 
omitted. 

15 

In message B7, the INVITE request is transmitted to the 
UE{B), which acknowledges, the INVITE request with a 200 
OK response iii message B8 . This 200 OK message is 
forwarded to the REP {i.e., the UE{A)) in messages B9 and 
20 BIO. Finally, UE(A) acknowledges the OK of UE{B) by 

sending an ACK request to UE(B) in messages Bll to B13 . 
Thereafter, the multimedia session can begin. 

With respect to the profile downloading in this case 
25 (i.e., message B5) , it is noted that in this case in 
particular the location information included in the 
subscriber profile is important. For example, maybe user 
UE(B) is not entitled to use his mobile station in the 
location where he currently is. Since the subscriber 
30 profile can basically divided in location (routing) 
information and service profile, it would also be 
sufficient in this case when only the location 
information (and/or service information which is location 
depending) is mandatorily downloaded to the I-CSCF. 
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As mentioned above, the representation of the subscriber 
profile in HTML is only an example, and, as ^ matter of 
course, other appropriate representations * can be used. 

5 The service profile part of the subscriber profile itself 
depends on the service execution architecture to be 
adopted in 3GPP for ROO. Basically, there are three 
possibilities: CAMEL (Customized Applications for Mobile 
network Enhanced Logic) , SIP and OSA (Open Service 
10 Architecture) . 

> 

The OSA (Open Service Architecture) defines an open API 
(Application Programming Interface) for the design, 
implementation, control and execution of services and 
15 applications provided by third party service providers. 

In case CAMEL is used for the service profile, then CSI 
(CAMEL Subscriber Information) using ASN.l representation 
is utilized for representing the service profile. 

20 

In SIP, the service profile can be a script written in a 
script language, which may be, e.g., a common script 
language like Call Processing Language (CPL) , Common 
Gateway Interface (CGI) or Java Enhanced SIP (JES) . 

25 

In case of OSA, any of the above described service 
profiles can be used in an appropriate way. 

The above description and accompanying drawings only 
30 illustrate the present invention by way of example. Thus, 
the embodiment may vary within the scope of the attached 
claims . 
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Claims 

1. A method for transmitting subscriber information 

5 from a first network element to a second network element, 
comprising the steps of 

inserting subscriber information in a specific • 
message (1) of the same call control protocol that is 
used to establish the call; and 
10 sending the message (1) from the first network 

element to the second network element. 

2. The method according to claim 1, further comprising 
the step of 

15 sending a confirmation message (2) from the second 

network element to the first network element in case the 
subscriber inforroation have been received successfully by 
the second network element. 

20 3. The method according to claim 1, wherein the call 

control message is a PROFILE request based on the Session 
Initiation Protocol (SIP) , the subscriber information 
being inserted in the message body of the request, 

25 4. The method according to claim 2, wherein the call 

control message is a PROFILE request based on the Session 
Initiation Protocol (SIP) , the subscriber information 
being inserted in the message body of the request, and 
the confirmation message (2) is a SIP 200 OK message, 

30 

5. The method according to claim 1, wherein the 
subscriber information is a subscriber profile. 

6. The method according to claim 1, wherein the first 
35 network element is a Home Subscriber Server (HSS) and the 
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second network element is a Call State Control Function 
(CSCF) . 

7. The method according to claim 6, wherein the Call 
5 State Control Function (CSCF) is a Serving Call State 

Control Function (S-CSCF) . 

8. The method according to claim 6, wherein the Call 
State Control Function (CSCF) is an Interrogating Call 

10 State Control Fiinction (I-CSCF) . 

9. The method according to claim 1, wherein the first 
network element is a Serving Call State Control Function 
(S-CSCF) and the second network element is an 

15 Interrogating Call State Control Function (I-CSCF) . 

10. A network system comprising a first network element 
and a second network element, wherein 

the first network element is adapted to insert 
20 subscriber information in a specific message (1) of the 
same call control protocol that is used to establish the 
call, and to send the message (1) to the second network 
element - 

25 11. The network system according to claim 10, wherein 
the second element is adapted to send a confirmation 
message (2) to the first network element in case the 
subscriber information have been received successfully by 
the second network element - 

30 

12. The network system according to claim 10, wherein 
the call control message is a PROFILE request based on 
the Session Initiation Protocol (SIP) , the subscriber 
information being inserted in the message body of the 
35 request. 
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13. The network system according to claim 11, wherein 
the call control message is a PROFILE request based on 
the Session Initiation Protocol (SIP), the subscriber 

5 information being inserted in the message body of the 

request, and the confirmation message (2) is a SIP 2 00 OK 
message. 

14. The network system according to claim 10, wherein 
10 the subscriber information is a subscriber profile. 

15. The network system according to claim 10, wherein 
the first network element is a Home Subscriber Server 
(HSS) and the second network element is a Call State 

15 Control Function (CSCF) . 

16. The network system according to claim 15, wherein 
the Call State Control Fiinction (CSCF) is a Serving Call 
State Control Function (S-CSCF) . 

20 

17. The network system according to claim 15, wherein 
the Call State Control Function (CSCF) is an 
Interrogating Call State Control Function (I-CSCF) . 

25 18. The network system according to claim 10, wherein 

the first network element is a Serving Call State Control 
Function (S-CSCF) and the second network element is an 
Interrogating Call State Control Function (I -CSCF) . 



30 
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FIG. 2 
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A2. REGISTER ^ 








A3. PROFILE DOWNLOADING 


^ A5. 200 OK 
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